home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 8021 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.7 KB
  1. Path: hubcap.clemson.edu!mjs
  2. From: mjs@hubcap.clemson.edu (M. J. Saltzman)
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: 29 Feb 1996 17:21:36 GMT
  6. Organization: Clemson University, The Great State of South Carolina
  7. Message-ID: <4h4nb0$cnj@hubcap.clemson.edu>
  8. References: <4gn5d8$t5f@newsbf02.news.aol.com> <4gril3$sn9@goanna.cs.rmit.EDU.AU> <31320777.2810@corp.dialog.com>
  9. NNTP-Posting-Host: hubcap.clemson.edu
  10.  
  11. In article <31320777.2810@corp.dialog.com> Paul Gorodyansky <paul_gorodyansky@corp.dialog.com> writes:
  12. >As I said, I just found out that my posting went also to
  13. > comp.lang.C group, in addition to PL/I group.
  14. >
  15. >[Incitement to commit langauge war...]
  16. >
  17. >   All you, C guys who replied, paid TOO MUCH attention to my note
  18. >about UNIONS, but it's a MINOR thing compared to other AWFUL for
  19. >an *application* programmer  things in C that I listed.
  20. >In systems/low-level tasks C may be Perfect.
  21.  
  22. We were focused on unions becasue that was the first article in the
  23. thread to appear in comp.lang.c.
  24.  
  25. >[C is bad because of...]
  26. >Just 2 examples of our NORMAL, REGULAR code (nothing special).
  27. >
  28. >I. Select/Switch statement. 
  29. >----------------------- 
  30. >  This important part of ANY *application* program is VERY
  31. >        ------- 
  32. >   rudimental and hard to use in C - you can use ONLY numbers here:
  33. >
  34. >switch(my_choice) { 
  35. >  case 0:  
  36. >....
  37. >  break;
  38. > case 1: 
  39. >....    
  40. >  break;
  41. >}
  42. >
  43. >You can use Enumerations in C but they are still only NUMBERS.
  44. >                                                      -------
  45.  
  46. Yes, C's switch construct is less well-designed then it might be (I'd
  47. like to see ranges on case labels, for example), but the following
  48. doesn't seem very compelling to me.
  49.  
  50. > In PL/I you can use any Expression (!) as a switch, that makes a
  51. > code close to specs and easy to read and modify:
  52. >      --------------     ------------     ------               
  53. >
  54. >Select(Source_Tag);
  55. >  When( 'AN' )
  56. >        ..... 
  57. >  When ( 'PD', 'PY', 'SO' )
  58. >         ... 
  59. >  When 
  60. >         ...
  61. >  When
  62. >         ...
  63. >End;
  64.  
  65. I'll concede that the comparable C is somewhat more tedious in this case.
  66.  
  67.  
  68.     if ( strcmp(Source_Tag, "AN") == 0 ) {
  69.       ...
  70.     } else if ( strcmp(Source_Tag, "PD") == 0 ||
  71.             strcmp(Source_Tag, "PY") == 0 ||
  72.             strcmp(Source_Tag, "SO") == 0 } {
  73.     } else if ( ... ) {
  74.  
  75.     }
  76.  
  77. One could use a lookup function to good advantage here.  But this
  78. particular example is as much about the fact that strings are not
  79. first-class types as it is about the limitations of the switch
  80. statement.
  81.  
  82. >    or something like that
  83. >
  84. >Select;                                                         
  85. >  When ( SUBSTR(INREC,4,1) = ' ' ) 
  86. >       ....                                                           
  87. >  When
  88. >       ...
  89. >  When ( INDEX(UPALPHA,Cur_Tag) > 0  &                           
  90. >         VERIFY(W_TAG23,'0123456789') = 0 )                     
  91. >       ....
  92. >  When ( String_1 || String_2 = String_3 )
  93. >        ...                                                       
  94. >End; 
  95. >
  96. >It is how SPECIFICATIONS look like, so for a person who works 
  97. >with this program  FIRST time, it is CLEAR, after reading specs,
  98. >what this part of code is doing.
  99. >     Just TRY to implement it in C !!!
  100. >You will HAVE TO find some 'work around', so it will be further
  101. >                                                        ------ 
  102. >from specs and the piece of the code will be much BIGGER and LESS 
  103. >clear, harder to understand.
  104.  
  105. The C idiom for this construct is:
  106.  
  107.   if ( SUBSTR(INREC,4,1) = ' ' ) {
  108.        ....
  109.   } else if ( ... ) {
  110.        ...
  111.   } else if ( INDEX(UPALPHA,Cur_Tag) > 0  &&
  112.          VERIFY(W_TAG23,'0123456789') = 0 ) {
  113.        ...
  114.   } else if ( strcmp(strcat(String_1, String_2), String_3) == 0 ) {
  115.        ...
  116.   }
  117.  
  118. It doesn't seem so tough to understand, or even so different.  What are
  119. PL/I semantics when more than one of the When conditions is true?
  120.  
  121. (Of course, String_1 was modified by the C code, but not by the PL/I
  122. code, but that's just a consequence of the way strings are treated
  123. by the standard library functions, not part of the "When versus
  124. switch" argument.)
  125.  
  126. >Just another example. Strings.
  127.  
  128. Others have pointed out that string libraries can be built to 
  129. handle most of these objections.  Yes, it's true that strings 
  130. are not a first-class type in C.
  131.  
  132. C is not perfect, but then again, neither is PL/I.  You can write
  133. unreadable, unmaintainable code in either, with no trouble at all.
  134. With a certain amount of care (perhaps marginally more in one language
  135. than the other in some casees), you can write readable, maintainable
  136. code in either as well.  Both languages have their "gotchas".
  137.  
  138. Beware, though, when critiquing langauge design, of the difference
  139. between things that are really bad and things that you're just not
  140. used to.
  141. -- 
  142.         Matthew Saltzman
  143.         Clemson University Math Sciences
  144.         mjs@clemson.edu
  145.